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Abstract 

"The Golden Age of Design may finally be upon us!" or so reported the New York Times in September 
of 2014. On the one hand everyday personal information appliances emphasized beauty and function. 
Apple™ took a lead by marketing the "feeling" of the iPod's design. The business world took notice and 
the cachet of designers soared both in terms of demand and compensation. Regrettably, the "golden 
age of design" has not swept the Information Systems (IS) discipline along with it. News stories weekly 
report huge project cost overruns, long delayed delivery dates, and complete project failures with 
irretrievable sunk costs. What explains the difference? Perhaps IS has not yet embraced the design 
mindset founded in professions prefixed by: architectural, fashion, industrial, graphic, product, urban, 
and interior. We examine the mindset of design professionals all but absent in IS education. This mindset 
fuels the enthusiasm for agile development methodologies. Appropriating it may be a relatively 
inexpensive re-centering of current IS pedagogy that can pay huge dividends for society down the road 
as information systems grow more and more essential throughout the commercial and private sectors. 
We explore this design mindset following Nigel Cross's retrospective on research in Designerly Ways of 
Knowing. With that as a frame we name five core elements of that mindset to frame IS pedagogy for 
design - First Principles of a Designerly Way of Knowing and propose guidelines for situating them in IS 
education. 

Keywords: IS design education, design pedagogy, tacit knowing, design theory, first principles of 
design 


1. INTRODUCTION 

The tenets upon which the information systems, 
IS, discipline rests are the pillars upon which our 
curriculum and pedagogy rest, and the lens we 
apply to stakeholders and constituents. IS as 
Davis and Olson (1985) characterize it is fairly 
canonical: the nexus of computer science, 
management and organizational theory, 
operations research, and accounting. Each of 


these disciplines has a "spanning" influence 
raising a broad range of concerns that overarch 
computing in its social context. 

Computing and information systems continue to 
be a dominant force in the daily life - a diffusing 
and diffuse innovation (Rogers & Shoemaker, 
1971). The pervasive and ubiquitous aspect of 
computing and information systems is both a 
backdrop (Carr, 2003; Lyytinen and Yoo, 2002) 
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as well as an acute driver of societal change 
(Bernstein at al., 2010). Despite the near 
omnipresence of information systems, failures 
remain headline-grabbing affairs, incurring 
considerable financial loss (Syal, 2013). As IS 
educators, it is our responsibility to ask in what 
role we might address this situation? 

This paper explores the challenges in information 
systems development and the nature of factors 
that recur among successful projects. We 
reference a history of IT project outcomes 
reported in the Standish Group's CHAOS reports. 
We examine the meaning of "success" framed 
through the lens of appreciative system (Vickers, 
1983). We reach beyond the bounds of computing 
to appropriate the manner that expert designers 
address ill-defined, "wicked" problems (Cross, 
2007). Based upon this understanding we 
propose first principles of a designerly way of 
knowing to guide the pedagogy of design for IS 
students as a complement to a mindset of 
reflective practice (Schon, 1983). 

We argue that design is an essential, core 
professional competency necessary for any 
successful system development project. And 
thus, design is essential to IS education. We 
recommend guidelines for design pedagogy that 
characterizes systems development as the 
creation of useful and usable artifacts. 

2. CHAOS: Systemic Recurring Failures 

Since 1995, the Standish Group publishes a 
yearly report of software and systems failures - 
both private and public (The Standish Group, 
1995, 2001). The CHAOS report surveys IT and 
project managers to study the characteristics of 
software and systems projects that succeed and 
fail. The report categorizes projects as: successful 
(completed on time and within budget); 
challenged (completed, but was one or more of 
the following: over-budget, over-time, or 
feature/function incomplete); or, impaired/failed 
(cancelled or not completed). Figure 1 shows a 5- 
year accounting of project assessment: 

Figure 1 shows software and systems project 
outcomes as less than "sure things." Although 
there may be flaws in and detractors of the 
CHAOS report (Ambler, 2014; Eveleens and 
Verhoef, 2010; Glass, 2006), the impact of the 
report is clear: the state of the art in systems 
development is less than reliable and 
success/failure rates of this proportion are not 
acceptable in disciplines like engineering or 
medicine. 


■ Successful ■Challenged ■Failed 



2011 2012 2013 2014 2015 


Figure 1. CHAOS Report outcomes 2011-15 

The 2015 CHAOS report (The Standish Group, 
2016) surveys factors commonly accepted by the 
Project Management Institute: on Time, On 
Budget, on Target, on Goal, Value and 
Satisfaction. We note ten of those factors in table 
1 categorized primarily as being most pertinent to 
either technological or people concerns. 


CHAOS 

Success 

Factor 

Technology 

People 

Executive 

Sponsorship 


X 

Emotional 

Maturity 


X 

User 

Involvement 


X 

Optimization 

X 

X 

Skilled 

Resources 

X 

X 

Standard 

Architectures 

X 


Agile 


X 

Parsimony 


X 

Project 

Management 

Expertise 


X 

Clear Business 
Objectives 


X 


Table 1. CHAOS Report outcomes 2011-15 
(The Standish Group, 2016) 

Table 1 does not prove that successful 
information systems development is solely a 
function of good project management. However, 
across a growing sample of respondents, the 
surveys that contribute to the CHAOS report 
generalize that organizational concerns play a 
primary role that require study. 
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Comparing Software Development Paradigms: 2013 

Lean 
Iterative 
Agile 
Ad-Hoc 
Traditional 

0 % 25 % 50 % 75 % 100 % 

■ Successful ■ Challenged ■ Failed 

Figure 2 - Project Success according to 
development paradigm 

Dr. Dobb's Journal published its own IT Project 
Success Rates survey from 2007 to 2013 and the 
2013 results are interesting not as much in the 
overall success rates, but in the apparent impact 
of development paradigm, Figure 2 (Ambler, 
2014). Projects that focus on frequent iterations, 
frequent delivery of product, and discursive 
balancing between stakeholders and developers, 
had greater success rates. 

Factors reflecting communication, collaboration, 
and project coherence resonate in both the Chaos 
and Dr. Dobb's reports. The degree to which the 
overall project vision is shared and there is a 
community wide conception of the project goal 
the greater the probability that the artifact that 
finally emerges meets the community's 
expectations. The organizational goals, 
constraints, culture, and needs combine and 
frame the project aspirations and foreshadow the 
prospective product artifact. 

3. RECONCILIATION, RESONANCE AND 
RESOLUTION IN DESIGNING AN ARTIFACT 

As a discipline, Information Systems endeavors to 
create human activity systems, which harness 
data and computing technology, to facilitate 
organizational goals and functions. This is a 
sociotechnical perspective, as in Emery and Trist 
(1969), recognizing the emergent and iterative 
nature of an information system as it evolves, and 
hopefully, thrives (Lee, 2010; Waguespack, 
2010). The sociotechnical perspective views an 
information system characterized by the mutual 
shaping influences that technology and 
organizational, as subsystems, exert within the 
information system. 

Figure 3 conceptualizes an information system as 
a confluence of a number of concerns - 
organizational, informational, and technological 
(Lee, 2010). These considerations can be 
conceptualized as subsystems within an 
information system, each exerting influence 
within the wider system. Generally, the realm of 
organizations and management represents a set 



of requirements for the system. However, both 
the data and the technology exert their own 
influence within the system as well. 


An Information System and 
Its Three Interacting. Constituent Subsystems 



Figure 3 - Interaction between the sub 
systems of an Information System from 
(Lee, 2010) 

Each of these subsystems has agency to some 
extent. In each subsystem the human actors 
reside amidst social and cultural components as 
well. These actors may align with disparate 
disciplines - each with their own assumptions: 
ontological, epistemological, praxeological, and 
phenomenological. For instance, it is possible to 
characterize the IS as existing betwixt 
management and computer science (Backhouse 
et al. 1991). The utility of this characterization is 
recognition that each discipline brings its own 
world-view to the relationships described in 
Figure 3. What codification of culture and 
communication does each community bring to the 
subsystem interactions? 

An information system may be considered from a 
transactional perspective: an occasion and 
opportunity to satisfy organizational problems 
(needs and aspirations) through technology - and 
data-driven solutions. The opportunity for 
information systems project failure arises in the 
attempt to join these perspectives. 

The discordance that arises in many IS 
implementation failures often appears as 
disconnect between the perspective inherent in 
organizational aspirations for a system and the 
perspective of the technologists who create the 
tools and artifacts which are consolidated and 
synthesized into solutions (Figure 4). 
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Figure 4 - Joining Perspectives on IS 

That we may further explore the phenomenon of 
discord between organizational and technical 
perspectives we turn to appreciative systems 
(Vickers, 1984). An appreciative system is a 
personally held conception of culture and values, 
essentially a world-view that mediates each 
individual's experience of the world. This world¬ 
view is the product of education and experience 
and as such is continually evolving. It determines 
the cues deemed worth attending to and forms a 
personal basis for judging the merits of 
everything. 

When actors and agents within the organizational 
subsystem communicate with actors and agents 
in the technology system, each does so in their 
vernacular, "codes," of their culture, discipline, 
and values. As an oversimplification, 
conversations may be an exchange of the same 
words, but the understanding may not always 
coincide with the intent. 

When two groups meet (those whose roles and 
functions in an organization resonate more with 
the technology system, and those whose roles 
and functions resonate with the organizational 
system), these groups may not have sufficiently 
compatible or aligned appreciative systems. This 
may be more than misalignments of language, 
but rather a form of discord that involves and 
extends from culture and values. 

The challenge of resolving discordant appreciative 
systems is prevalent in ill-defined and "wicked" 
problems. It is also a recurrent aspect of 
information systems development projects and 
contributes to the frequency of failed projects. 
The convergence of social aspirations and the 
technology of building systems can only be 
resolved through the creation of bridging 
concepts that allow the organizational aspirations 
to be realized in artifact properties. Design as a 
skill, an art, a profession has always been the 
basis of such a bridging. 


4. DESIGNERLY WAYS OF KNOWING 

The practice of design in the computing arena has 
traditionally followed the lead of its ancestral 
disciplines in the sciences founded on the premise 
of technical rationality. 

Technical Rationality depends on agreement 
about ends. When ends are fixed and clear, 
then the decision to act can present itself as 
an instrumental problem. (Schon, 1983, 
P-41) 

This premise of technical rationality basically 
posits that design is problem solving where the 
"solution" is determined through an exhaustive 
search of every possible alternative to achieve the 
optimal result. 

According to Herbert Simon ... the process of 
rational decision-making is an act of 
choosing among alternatives which have 
been assigned different valuations. It 
involves the following process: 

1. Listing all of the alternative strategies. 

2. Determining all the consequences that 
follow upon each of these strategies. 

3. Comparatively evaluating these sets of 
consequences. 

Simon, however, admits that total rationality 
is an unattainable idealization in real 
decision-making - who can be aware of all 
existing alternatives? 

(Simon quoted by Skyttner, 2005) 

Perhaps the translation of a mathematical 
equation into the code of a programming 
language may be classified as problem solving, 
but when the stakeholder community is 
realistically accounted for in information systems 
design, there is no calculable, optimal "solution." 
This "social" dimension casts the design of 
information systems as ill-defined or "wicked" 
problems. (Skyttner, 2005, p. 460) 

As a "wicked" problem, designing information 
systems requires a conception of design that 
shapes the design task with a goal of satisfaction 
rather than optimality. (Samuelson, 1977) Thus 
we turn to the Designerly Ways of Knowing, 
DWOK, Nigel Cross's compendium of major 
research contributions to design understanding in 
order to explore design as the construction of 
artifacts in the design space confounded by the 
intersection of technology and society. (Cross, 
2007) 
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Phenomenon 

Methods 

Values 

Science 

The natural 
world 

Controlled 

experiment, 

classification, 

analysis 

Objectivity, 
rationality, neutrality, 
“truth” 

Humanities 

Human 

experience 

Analogy, 

metaphor, 

evaluation 

Subjectivity, 

imagination, 

commitment,” 

justice” 

Design 

The artificial 
world 

Modeling, 

pattern- 

formation, 

synthesis 

Practicality, 
ingenuity, empathy, 
“appropriateness” 


Table 2. Conceptions on Design 

As Cross (2007, p.18) summarizes it, design 
traditionally assumes one of three stripes as 
depicted in Table 2. Design in the sciences versus 
humanities is objectivity versus subjectivity or 
experiment versus analogy. The realm of 
professional designers (e.g. architecture and 
engineering) engages in constructing or creating 
new things rather than explaining what already 
exists. 

The basic challenge of information systems 
design is two-fold: 1) the characterization of the 
desired relationship between the stakeholder 
community and the artifact, and 2) the 
construction of the artifact that delivers the 
appropriate behavior to sustain that relationship. 
The design task is to comprehend the aspiration 
instigating the stakeholders' desire for the artifact 
and to reflect that aspiration in the 
stakeholder(s)' experience of the artifact. Design 
must grasp the intension rather than 
requirements for the artifact. Furthermore, the 
human nature of the stakeholders ensures that 
the entire system is not static, but dynamic, 
because aspirations evolve with their experience 
of the artifact and the environment that enfolds 
both stakeholders and artifact evolves because 
of, and in spite of, both of them. Rather than 
prescribing a design methodology, Cross 
describes a mindset, an attitude, observed 
repeatedly among highly successful designers 
that facilitates the formation of consistently 
satisfying designs. We draw liberally from Cross's 
survey and explore his findings as follows. (Cross, 
2007) 

It is widely accepted that design 'problems' 
can only be regarded as a version of ill- 
defined problems. In a design project it is 
often not at all clear what 'the problem' is; it 
may have been only loosely defined by the 
client, many constraints and criteria may be 


undefined, and everyone involved in the 
project may know that goals may be re¬ 
defined during the project. In design, 
'problems' are often defined only in relation 
to ideas for their 'solution', and designers do 
not typically proceed by first attempting to 
define their problems rigorously. (Cross, 
2007, p. 99) 

Typically, in a succession of trial solutions each 
attempt provides a concrete object with which to 
constructively challenge the stakeholders' 
confidence in their expressed intensions and to 
refine an apposite vocabulary to hone the 
dialogue between stakeholders and designers 
that exposes "what's working" and "what's not!" 
Each prototype reveals a degree of accord (or 
discord) between intensions and artifact. 
"Proposed solutions often directly remind 
designers of issues to consider. The problem and 
solution co-evolve." (Kolodner & Wills, 1966) 

[Ojnly some constraints are 'given' in a 
design problem; other constraints are 
'introduced' by the designer from domain 
knowledge, and others are 'derived' by the 
designer during the exploration of particular 
solution concepts. (Ullman, 1988) 

DWOK cultivates an unfolding of the artifact's 
properties, but also a continuous re-certification 
of the stakeholders' intensions. 

Designers are not limited to 'given' 
problems, but find and formulate problems 
within the broad context of the design brief. 
This is the characteristic of the reflective 
practice identified by Schon (1983) as 
problem setting: 'Problem setting is the 
process in which, interactively, we name the 
things to which we will attend and frame the 
context in which we will attend to them'. 
(Schon quoted by Cross. Cross, 2007, p. 
101 ) 

The prototype (on paper, in mockup, in 
simulation, etc.) centers the design process on 
personal experience and draws out the 
stakeholders' feelings and thereby their world¬ 
view, their sense of appreciation, and what they 
value about the artifact. This last element, what 
they value, is core to the DWOK, the role of 
appreciative system. (Vickers, 1983) 

The appreciative settings condition new 
experience but are modified by the new 
experience. Such circular relations Vickers 
takes to be the common facts of social life, 
but we fail to see this clearly, he argues, 
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because of the concentration in our science- 
based culture on linear causal chains and on 
the notion of goal-seeking. 

(Checkland, 1999, p. 262) 

Interestingly enough, Vickers refers to the 
stakeholders' expression of their intensions as 
their code! (Vickers, 1983) "Code" is a familiar 
term for IS developers, but Vickers has a more 
expansive conception of it that envelops both 
their expression of intensions and their 
appreciative system. And therefore what they 
express, rather than specific implementation 
elements, is metaphoric or representative of their 
intensions. 

'Metaphoric appreciation' is an apt name for 
what it is that designers are particularly 
skilled in, in 'reading' the world of goods, in 
translating back from concrete objects to 
abstract requirements, through their design 
code. (Cross, 2007, p. 27) 

The design process continues as a dialog, a 
conversation, between stakeholder aspirations 
and the unfolding artifact. The cycle forms an 
exercise of mutual learning as each generation of 
the artifact illuminates and refines both the 
stakeholders' intensions and the suitability of the 
designer's choices. 

A designer begins a conceptual design 
session by analyzing the functional aspects 
of the problem. As the session progresses, 
the designer focuses on the three aspects of 
function, behavior and structure, and 
engages in a cycle of analysis, synthesis and 
evaluation. Towards the end of the design 
session, the designer's activity is focused on 
synthesizing structure and evaluating the 
structure's behavior. (McNeil et al., 1998) 

The designers choose design actions to shape 
each prototype informed by their own 
appreciative system tailored by their knowledge 
of the design domain and the medium of 
construction - an appreciative system formed 
through education, training, and practical 
experience. 

The designer knows (consciously or 
unconsciously) that some ingredient must be 
added to the information that he already has 
in order that he may arrive at an unique 
solution. This knowledge is in itself not 
enough in design problems, of course he has 
to look for the extra ingredient, and he uses 
his powers of conjecture and original thought 
to do so. What then is this extra ingredient? 


In many if not most cases it is an "ordering 
principle." (Levin, 1966) 

This appreciative system influences design 
decisions that strengthen: a) the fidelity of the 
artifact with the stakeholders' intensions and 
b) the artifact's plasticity in an environment of 
inevitable change. 

The portrayal of a Designerly Way of Knowing in 
the research that Cross summarizes characterizes 
a design project as a confluence of human 
perceptions and aspirations extruded through the 
technology of construction and rendition. This 
activity unfolds in an environment where all of the 
above inevitably evolve as they are impacted by 
one another. The whole of an IS design project is 
an "ill-defined" and "wicked" problem. And 
although optimality is impractical, design success 
is feasible if the design process is committed to 
first principles consonant with the DWOK. 

5. FIRST PRINCIPLES OF A 
DESIGNERLY WAY OF KNOWING 

A first principle is a basic, foundational, self- 
evident proposition or assumption that cannot be 
deduced from any other proposition or 
assumption. The principles that follow distill 
aspects of the mindset observed in the protocols 
of expert designers and their engagement with 
stakeholders. Although we continually address 
designers separately, they are definitely 
stakeholders in their own right. 


Human Knowing and 
Conscious Expression 
Are Imperfect 


The Operative 
Appreciative Systems 
Determine the Whole of 
the Design Space 


First 

Principles of a 

! Designerly 
Way of 
Knowing 


The Medium of 
Construction Determines 
the Design Choices 


Design is Continuous 
Exploring and Learning 
in a Dynamic 
Environment 



Design Reconciles 
World-Views 


Figure 5 - First Principles of DWOK 

Human Knowing and Conscious Expression 
Are Imperfect 

If human knowing and their utterances were 
perfect all human behavior could be 
demonstrated algorithmically as with pure logic. 
In fact human behavior and decision-making 
processes always exhibits the involvement of tacit 
knowledge. 
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We marvel at the story of the firefighter who 
has a sudden urge to escape a burning house 
just before it collapses, because the 
firefighter knows the danger intuitively, 
'without knowing how he knows:' However, 
we also do not know how we immediately 
know that a person we see as we enter a 
room is our friend Peter. The moral ... is that 
the mystery of knowing without knowing is 
... the norm of mental life. 

(Kahneman, 2011) 

Kahneman's interest in tacit knowing weaves 
throughout his study of human decision making 
in economics from choosing laundry products to 
assessing the reliability of financial institutions. 
The act of design continually engages tacit 
knowing. 

Stakeholders [and designers] access their 
knowledge through explicit or tacit 
"knowing." A stakeholder can specify/explain 
their explicit knowledge (i.e. knowledge 
acquired through formal education) and be 
aware of but, not be able to specify/explain 
their tacit knowledge (i.e. knowledge 
acquired through their personal experience 
of "living"). This is the distinction between 
knowing "what" and knowing "how" (i.e. "We 
know more than we can tell"). 

(Polanyi, 1966, Waguespack, 2016) 

The fact of tacit knowing is the reason that design 
is as much art as science. The fact that all 
possible alternatives cannot be known in advance 
is why technical rationality is a false model of 
human behavior. Description in metaphor is a 
constant channel for connecting with tacit 
knowledge. And thus, a prime function of design 
is teasing out that knowledge. Although it may be 
tacit, it materially impacts the primary goal of 
design, satisfaction. 

The Operative Appreciative Systems 
Determine the Whole of the Design Space 

Whether held explicitly or tacitly, stakeholders 
and designers apply a personally held 
appreciative system to their perception of the 
world. That appreciative system is in fact their 
world-view. That view determines what cues they 
notice in their everyday activities and what 
properties of those experiences determine their 
sense of approval or displeasure. To the extent 
that stakeholders share a background of culture, 
education, or life experience there may be 
significant accord across their appreciative 
systems. And where this shared background does 
not exist, design must build bridges to attain 
"peaceful coexistence" or value resolution. 


Design is Continuous Exploring and 
Learning in a Dynamic Environment 

A central characteristic of both tacit knowing and 
appreciative systems is their continuous 
evolution. Together they are a product of "living:" 
the life experience of the stakeholders, the 
designer(s), and "living" with the artifact. Change 
is continuous and ubiquitous. It occurs in the 
stakeholders' environment through markets, 
government, politics, the changing community of 
stakeholders, etc. It occurs with the evolution of 
technology: theory, communication, 

computation, etc. First and foremost, the 
stakeholders' experience with the artifact of the 
design process itself changes everything. The 
design space is an ecosystem of mindsets, 
aspirations, and feedback. 

One of the unique aspects of design behavior 
is the constant generation of new task goals 
and redefinition of task constraints. (Akin, 
1979) 

Accounts of the design activity repeatedly 
demonstrate that stakeholders' aspirations 
evolve, as does the nature of the artifact. "The 
problem and solution co-evolve." (Kolodner & 
Wills, 1966) Indeed, this characteristic of 
organically evolving the artifact is a signature of 
agile development methodologies - "building 
lean:" only as much as is needed; when we know 
we need it. 

The Medium of Construction Determines the 
Design Choices 

Among the resources the designers bring to the 
design task is their skill with the medium of 
construction - the implements of fabrication, 
prefabricated frameworks, vocabularies, and 
(most important of all) the seasoned practice of 
applying these tools in design projects. Here the 
designer is a "performer" in the vein of an 
accomplished musician, sports athlete, surgeon, 
painter, or sculptor. These performers achieve an 
internalization of their instrument, the bat or ball, 
the scalpel, the brush, or the chisel. For the 
skilled performer it is as though the instrument 
becomes an extension of their own person - they 
know "what," "why," and "how" in the doing. They 
are one with their craft. 

When exercising a skill, we literally dwell in 
the innumerable muscular acts which 
contribute to its purpose, a purpose which 
constitutes their joint meaning. Therefore, 
since all understanding is tacit knowing, all 
understanding is achieved by indwelling. 

(Polanyi, 1969) 
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The designer's indwelling with these tools 
determines the form and dimensions of the 
artifact - what can be represented or expressed 
in this medium. In a real sense they determine 
what the designer is able to "see" and thus, what 
is imaginable in the artifact. This is the designer's 
world-view - what artifact is possible. 

Design Reconciles World-Views 

As we began this exploration of a designerly way 
of knowing, the basic challenge of information 
systems design is two-fold: 1) the 

characterization of the desired relationship 

between the stakeholder community and the 
artifact, and 2) the construction of the artifact 
that delivers the appropriate behavior to sustain 
that relationship. 

What the stakeholders' desire is conceived and 
expressed through a lens of their world-view. 
What the designer is capable of constructing is 
shaped through the designer's world-view. 

Design success is achieving the desired 

relationship as "seen" through both of the 
respective world-views. The product of design is 
a practical artifact in which the stakeholders can 
perceive their intensions. In effect the design task 
is an artifact that reconciles the various operative 
world-views, appreciative systems. There is a 
tradition that the reconciliation requires a 
"creative leap." 



Figure 6 - Duck-Rabbit Image Puzzle 

The 'creative leap' is not so much a leap 
across the chasm between analysis and 
synthesis, as a throwing of a bridge across 
the chasm between problem and solution. 
The 'bridge' recognizably embodies 
satisfactory relationships between problem 
and solution. It is the recognition of the 
satisfactory concept that provides the 
'illumination' of the creative 'flash of insight'. 

The recognition of a proposed design concept 
as embodying both problem and solution 
together may be regarded as something like 
the well-known duck-rabbit puzzle; it is 
neither one nor the other, but a combination 


which resolves both together and allows 
either to be focused upon. 

(Cross, 2007, p. 78) 



Figure 7 - World-Views Reconciled 

This description of a designerly way of knowing 
does not prescribe a specific design theory or 
even a methodology. The focus is a mindset of 
systems thinking and practice of continuous 
dialog between stakeholders and designers to 
transact and build a shared understanding of 
what a "successful" artifact means in the design 
space they share. The challenge for IS education 
is to find ways to integrate this mindset of design 
in IS pedagogy. 

6. FORMING THE DWOK 
IN THE STUDENT OF IS DESIGN 

Educating the IS design student can take many 
forms. Rather than prescribe a pedagogy or 
curriculum, the following learning objectives 
outline the knowledge elements that resonate 
with a designerly way of knowing: 

Practice Knowledge of a Domain 

Understanding client intensions and crafting a 
shared design space requires realistic experience 
of "walking a mile in the client's shoes." The 
student needs enough practical domain 
knowledge to support the dialog between client 
and designer. In business school programs the 
domain is commerce: accountancy, finance, 
marketing, etc. Other domains may be 
engineering, medicine, or the physical sciences. 

Technology Theory and Practice 

The theory and practice of the relevant 
technology of construction are integral to the 
designer's world-view - again to inform the 
intercourse with the client's world-view. Design 
skill rests on "knowing how" as well as "knowing 
what" to the level at least of apprentice 
professional capability. 


©2017 ISCAP (Information Systems & Computing Academic Professionals) 
http ://iscap.info; http://isedj .org 


Page 69 




Information Systems Education Journal (ISEDJ) 
ISSN: 1545-679X 


15 (6) 
November 2017 


System Life Cycle Project Experience 

An appreciation of the interplay between 
intensions and design actions must be learned by 
experience: making, applying, and assessing 
design action decisions with particular attention 
to immediate and longer-term consequences. 
Reflective cycles for forming and reforming 
artifacts reinforces a life cycle consciousness. 

Discriminating Between Requirements and 
Design Choices 

A prime goal of the designer / stakeholder 
authorship of the shared appreciative system 
they cast over the design space is to focus design 
decisions on essential elements of satisfaction. 
Every design choice incurs tradeoffs in quality 
and/or effectiveness. A design faithful to the 
intensions of the stakeholders must discriminate 
between tradeoffs arising from essential artifact 
properties and accidents of implementation due 
to implementation technology idiosyncrasies. 
(Waguespack, 2010, p. 93) 

Collaboration and Development 
Methodology 

Team skills (collaboration, negotiation, and 
"technical" writing) aligned with a practical 
systems development methodology establish 
basic project competency - a learning 
environment for designer as student or 
professional. Above all, effective design depends 
upon open, free, and honest communication 
throughout the artifact's community. 

Incubating Creativity 

Creativity is intrinsic to design. Most dictionaries 
add "especially in the production of an artistic 
work." That is the point, IS design as a "wicked" 
problem has much to do with art. Students need 
encouragement to seek out novel perspectives, 
interpretations, reactions, or descriptions in the 
design space. The naming and framing is a 
creative act that requires an open-minded 
perspective, imaginative tools, and generative 
metaphors. (Schon, 1983) Design pedagogy in IS 
needs room for dreaming and exploring these 
world-views with as little instructional prejudice 
or constraint as possible. The concept of design 
studio common in architecture and industrial 
design needs a home in IS pedagogy as well! 
(West et al., 2005) 

7. DISCUSSION 

A designerly way of knowing prefigures a design 
methodology capable of attending to ontological, 
epistemological, praxeological, axiological and 
phenomenological dimensions of information 
systems. We have intimated the link between the 


discordant appreciative systems and the 
frequency of development project failures. 
Substantiation of the link requires additional 
study. Although Cross's retrospective on the 
behavior of expert designers has focused 
predominantly outside the information systems 
artifact realm, the parallels in IS are self-evident. 
Our next step of inquiry is to prototype curricular 
vehicles to demonstrate and test the pedagogical 
guidelines presented herein. 
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